POV-Ray : Newsgroups : povray.general : Scanline rendering in POV-Ray : Re: Scanline rendering in POV-Ray Server Time
4 Aug 2024 18:20:44 EDT (-0400)
  Re: Scanline rendering in POV-Ray  
From: Tom York
Date: 5 Jun 2003 05:50:01
Message: <web.3edf118dc1329458bd7f22250@news.povray.org>
Christopher James Huff wrote:
>True, as I said, they were reduced to triangles. The API could probably
>hook up to built-in primitives if they were available, though.

Oh, no doubt. You might be able to implement an OpenGL-conformant interface,
so that the teapot really does go through as a primitive to the card... :-)

>Real-time involves several simplifications in computation and geometry,
>which does push the advantage to scanline. But do you need 200FPS? If
>the raytracing card is *fast enough*, its advantages could outweigh
>those of a scanline card.

I expect most people would be happy with 30 fps or above (some people need
higher in multiplayer games, but they turn off detail). If the card cannot
match other cards on scenes of similar complexity at that rate, it will be
visually annoying.

>(There was some RTRT...Real Time Ray-Tracing...demo called something
>like Heaven 7, you may want to look at it. It was quite impressive on my
>PC.)

Yes, and Rubicons 1 and 2, and Fresnel 1 and 2. The Rubicons did the
raytracing at low resolution and used interpolation. Fresnel 2 (and 1?)
actually took advantage of a 3D card to accelerate the raytracing,
apparently. Heaven 7 looks incredibly good (it only needed one light source
and no shadow checking!). All of these did no space subdivision (no octrees
or BSP methods). Are there then only RTRT *demos*? No equivalent of the
various toy engines that you can find on places like the 3D Engine List?

>I didn't say they were useless. Triangles are definitely useful for
>things like terrain, though I wonder if a hardware isosurface solver
>could compete...

It takes long enough on an Athlon to solve those things...

>And the advantage of a box is memory: one box takes up less memory than
>one triangle. You *can* use groups of them, nobody has said you would be
>limited to single primitives.

Sure, but people tend to minimise geometry in favour of textures in games. I
know it's often the other way round on non-PC graphics systems (hence
OpenGL being caught behind the times when DirectX started supporting all
these fancy texturing methods), so perhaps a primitive rich card would
reverse this.

>There was a POV-Ray include that used CSG to "explode" objects. If that
>method wasn't suitable, an animated mesh would probably be the best way
>to go. Again, I'm not saying meshes are useless, just that there are
>often better things to use.

I know, I've used it (and very useful it is too :-) However, isn't
differencing famously slow? Also, wouldn't a differenced object be doing
calculations for all the empty "subtracted" pixels as well?

>This is pretty much irrelevant. I just said you can add and remove
>geometry. What you are talking about would be more switching between
>different models for different frames of the animation.

I see.

>Who said no triangles? "More primitives" != "Ban triangles"!

I'm guessing that triangles would remain the most popular shape, except in
the simplest room-based games (irrespective of technical arguments, it
would take a while for programmers/artists to start using the other
primitives extensively).

>With a raytracing engine, the sphere would likely be faster than the
>crossed polygons.

I've no idea whether that's true, but I imagine it's unlikely to be true
with a volumetrically shaded sphere.

>I was not talking about texture-mapped spheres. I was specifically
>talking about using procedural shaders: something volumetric or based on
>angle of incidence to the surface, or something more like the glow patch.

Aren't atmosphere/volumetric effects often faster with scanline methods (I
don't know)?

>You're assuming all the texture maps and models fit in the card memory.
>Yes, when the image map is already local, using it would be faster than
>all but the simplest shaders. That doesn't mean procedural shaders are
>too slow. If a specific shader is too slow, you use a faster one, maybe
>resorting to an image map if it will do the job and there is memory for
>it.

They usually do, because the programmers know what sort of minimum memory
requirements on the card they're prepared to tolerate. When they don't, you
really notice. However, using predominantly procedural shaders you throw
the bottleneck on the card's processor, and card memory is cheaper.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.